Packet header field extraction

ABSTRACT

Some embodiments provide a method for processing a packet for a pipeline of a hardware switch. The pipeline, in some embodiments, includes several different stages that match against packet header fields and modify packet header fields. The method receives a packet that includes a set of packet headers. The method then populates, for each packet header in the set of packet headers, (i) a first set of registers with packet header field values of the packet header that are used in the pipeline, and (ii) a second set of registers with packet header field values of the packet header that are not used in the pipeline.

BACKGROUND

In Software Defined Networking (SDN), the control plane is physicallyseparated from the forwarding plane and communicates with the forwardingplane through an interface (e.g., the OpenFlow protocol). OpenFlow is anevolving networking standard that uses a match-action paradigm fornetwork packet switching. The typical hardware switches that were (andstill are) used to implement the match-action paradigm, however, are notquite flexible since they process only a fixed set of fields with alimited repertoire of packet processing actions. A reconfigurable matchtable (RMT) architecture that overcomes the aforementioned shortcomingshas recently been introduced to the market. This new architecture couldbe improved to make the hardware switch operate more efficiently.

SUMMARY

Some embodiments provide a novel packet processing pipeline thatenhances the match-action packet header processing performed byreconfigurable hardware switches. The hardware switch of someembodiments includes, among other elements, an ingress pipeline and anegress pipeline. Each pipeline includes a parser, a match-action unit(MAU), and a deparser. In some embodiments, for each packet that isprocessed by the switch, the parser separates the packet header data(e.g., Ethernet headers, IPv4 headers, TCP headers, etc.) from thepayload of the packet and determines which fields of each packet header(e.g., source port address of the TCP header, destination port addressof the TCP header, etc.) might be processed by the MAU. The parser ofsome such embodiments (1) populates a primary packet header vector(PPHV) with only the fields of the different headers that may be used bythe MAU, and (2) populates a secondary packet header vector (SPHV) withthe rest of the fields of the different headers (i.e., the fields thatwill not be processed by the MAU). In some embodiments, the PPHV andSPHV each includes a set of registers that stores the packet headerfields during processing by the MAU.

In some embodiments, the parser delivers the populated PPHV to the MAU,which includes a set of match-action stages for matching the differentheader fields of the packet against the different match tables andapplying the required actions to the packet by modifying the packetheader data (e.g., assigning the packet to an output port and queue,sending the packet to a network controller, dropping the packet, etc.).The parser of some such embodiments also delivers the populated SPHVdirectly to the deparser (without having the MAU process the SPHV) alongwith the payload of the packet.

In some embodiments, after the different packet headers are processed bythe MAU, the deparser reassembles the packet with (1) the processedheader data (e.g., modified header fields) of the PPHV that the deparserreceives from the MAU, (2) the unprocessed header data stored in theSPHV that the deparser receives from the parser directly, and (3) thepayload of the packet that the deparser also receives from the parser.After reassembling the packet, if the packet is reassembled by aningress deparser, the deparser sends the packet to a queuing system tobe subsequently forwarded to the egress pipeline of the switch. On theother hand, if the packet is reassembled by an egress deparser, thedeparser sends the packet (with a header that might or might not havebeen modified) out of the switch.

The parser of some embodiments determines which fields of each packetheader may be processed and which fields will not be processed by theMAU, based on the information the parser receives from the packetheaders themselves (e.g., the EtherType field of the packet, etc.), andbased on configuration data received from the control plane. In someembodiments, a compiler in the control plane receives the data requiredfor configuring the pipeline (e.g., through a programing language code),generates a set of configuration data, and distributes the generateddata to a configurator module (also part of the control plane). Theconfigurator module then distributes the configuration data to both theparser and MAU of the pipeline in the switch.

The parser of some embodiments, based on the information it receivesfrom the configurator, determines which sets of packet headers toextract from the packet and how to extract these packet headers. Theparser analyzes the packet headers as it extracts them according to theconfiguration data configured by the control plane. This configurationdata represents a parse graph that identifies how to parse the packetbased on values of certain packet header fields as well as table flowand control flow graphs used to generate the configuration data for theMAU, which describe how packets will be processed through the stages ofthe MAU. Based on the configuration data and the values of certainpacket header fields, the parser determines iteratively (i) whether eachpacket header field should be placed in the PPHV or the SPHV and (ii)how to extract the next set of packet header fields. For instance, theEtherType field of the layer 2 header of some embodiments specifies howto extract the layer 3 header (e.g., whether the packet is IPv4 or IPv6,etc.).

Separating the fields that may be processed by the MAU from the rest ofthe fields in each packet header improves the overall efficiency of theswitch in many ways. For instance, this separation helps avoid wastingthe valuable resources of the MAU by enabling these resources to only(or primarily) process data that is actually needed for making thepacket processing determinations. For example, a TCP packet headertypically has a minimum length of five words (twenty bytes). In manycases, the MAU of the pipeline processes only four bytes of the TCPheader bytes (i.e., the source and destination port addresses) and therest of the fields in the TCP header (sixteen bytes) are not used by anyof the stages of the MAU. In such cases, by separating the unused datafrom useful data, the parser does not waste any of the valuableresources of the MAU to process the other sixteen bytes of the TCPheader.

In addition, separating the PPHV from the SPHV enables the parser toparse deeper into packets while sending the same amount of data to theMAU (via the PPHV). While using a single PPHV of a fixed size onlyallows the parser to extract the packet headers up to a certain point(the size of the PPHV), sending some of the unused fields into the SPHVallows the PPHV to carry only the more useful fields, and include deeperpacket headers. For example, newer tunneling protocols such as GENEVEadd variable length option fields to the packet header, and may be quitelong. Similarly, packets sent using multi-layer tunneling may havesignificant amounts of packet header data that may need to be extractedin order to reach the layer 4 (e.g., TCP) data. By sending the fieldsthat will not be processed by the MAU to the SPHV, the PPHV can includepacket header fields that are located deeper into the packet, withoutsending additional data to the MAU.

The preceding Summary is intended to serve as a brief introduction tosome embodiments of the invention. It is not meant to be an introductionor overview of all inventive subject matter disclosed in this document.The Detailed Description that follows and the Drawings that are referredto in the Detailed Description will further describe the embodimentsdescribed in the Summary as well as other embodiments. Accordingly, tounderstand all the embodiments described by this document, a full reviewof the Summary, Detailed Description and the Drawings is needed.Moreover, the claimed subject matters are not to be limited by theillustrative details in the Summary, Detailed Description and theDrawings, but rather are to be defined by the appended claims, becausethe claimed subject matters can be embodied in other specific formswithout departing from the spirit of the subject matters.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the invention are set forth in the appendedclaims. However, for purpose of explanation, several embodiments of theinvention are set forth in the following figures.

FIG. 1 illustrates a block diagram of a hardware switch and a blockdiagram of an ingress/egress interface of the hardware switch.

FIG. 2 illustrates a block diagram that shows that the parser produces asecondary packet header vector (SPHV), besides the primary packet headervector (PPHV), that bypasses the MAU and is directly delivered to thedeparser.

FIG. 3 illustrates an ingress/egress pipeline architecture thatseparates the participating header fields of the different packetheaders from nonparticipating packet header fields of a packet.

FIG. 4 conceptually illustrates the reason that the parser of someembodiments does not store the entire packet headers in the PPHV to beprocessed by the MAU.

FIG. 5 conceptually illustrates a block diagram of a parser that isconfigured by a compiler to separate the participating (in an MAUprocess) packet header fields from nonparticipating header fields.

FIG. 6 conceptually illustrates a process of some embodiments thatpopulates the PPHV and SPHV with different header fields of a packetheader.

FIG. 7 conceptually illustrates a compiler of some embodiments forgenerating parser and MAU configuration data.

FIG. 8 conceptually illustrates a process performed by the compiler ofsome embodiments to generate parser configuration data for a hardwareswitch that parses packet header data into a PPHV and a SPHV.

FIG. 9 conceptually illustrates an electronic system with which someembodiments of the invention are implemented.

DETAILED DESCRIPTION

In the following description, numerous details are set forth for thepurpose of explanation. However, one of ordinary skill in the art willrealize that the invention may be practiced without the use of thesespecific details. In other instances, well-known structures and devicesare shown in block diagram form in order not to obscure the descriptionof the invention with unnecessary detail.

Some embodiments provide a novel packet processing pipeline thatenhances the match-action packet header processing performed byreconfigurable hardware switches. The hardware switch of someembodiments includes, among other elements, an ingress pipeline and anegress pipeline. Each of these pipelines includes a parser, amatch-action unit (MAU), and a deparser.

FIG. 1 illustrates a block diagram of a hardware switch 110 and a blockdiagram of an ingress/egress pipeline of the hardware switch. Morespecifically, the hardware switch 110 includes an ingress pipeline(datapath) 115, a queuing system (e.g., a data buffer) 120, and anegress pipeline 125. The ingress pipeline 115 of some embodimentsreceives a packet 105 (e.g., through an I/O module), parses the packetinto a packet header vector (PHV), sends the PHV through a set of matchand action stages which may modify the PHV, deparses the packet headersback from the PHV into packet format, and enqueues the packet in acentralized data buffer (i.e., the data buffer 120). Each one of theaforementioned operations is described in more detail below by referenceto the ingress/egress pipeline 140.

In some embodiments the queuing system 120 receives the packets that areprocessed by the ingress pipeline and provides a large shared buffer(storage) that accommodates the queuing delays due to oversubscriptionof the output channels of the ingress deparser. In some embodiments, thedata buffer stores packet data, while pointers to that data are kept indifferent queues per channel. Each channel in turn requests data fromthe common data buffer using a configurable queuing policy. Whenpointers to packets reach the head of the queues, the packets are readout of the data buffer 120 into the egress interface 125.

Similar to the ingress interface 115, the egress interface 125 of someembodiments receives the packet from the queuing system 120, separatesthe packet payload from the packet headers, stores the packets headersin a PHV, sends the PHV through an ingress pipeline of match and actionstages, deparses the packet headers back from the PHV into packetformat, and sends the packet 130 to an appropriate output port of theswitch 110 to be driven off the switch (e.g., through one of the outputchannels). The output packet 130 may be the same packet as the inputpacket 105 (i.e., with identical packet headers), or it may havedifferent packet headers compared to the input packet 105 based on theactions that are applied to the packet headers in the ingress and egresspipelines (e.g., different header field values for certain header fieldsand/or different sets of header fields).

One of ordinary skill in the art would realize that the illustratedblocks in switch 110 are exemplary only. The ingress, queuing, andegress blocks are simplified for simplicity of the description. Forexample, although the figure shows only one entry point to the ingressparser and one exit point from the egress deparser, in some embodimentsthe input signals are received by many different input channels (e.g.,64 channels) and the output signals are sent out of the switch fromdifferent output channels (e.g., 64 channels). Additionally, althoughfor the illustrated switch only one parser interface is shown for theingress/egress pipeline 140, some embodiments employ numerous parserblocks (e.g., 16 parser blocks) that feed the match-action unit (MAU) ineach pipeline.

FIG. 1 also shows a block diagram 140 of an ingress/egress interface ofthe hardware switch 110. The interface includes a pipeline with threedifferent units, namely a parser unit 145, a match-action unit (MAU)150, and a deparser unit 155. The parser 145 of some embodimentsreceives the incoming packet data and produces a PHV as its output. Inother words, the parser 145 separates the packet headers from the packetpayload by extracting the different packet headers and storing them inthe PHV. In some embodiments the PHV includes a set of different sizeregisters or containers. For instance, in some embodiments the PHVincludes sixty-four 8-bit registers, ninety-six 16-bit registers, andsixty-four 32-bit registers (for a total of 224 registers containing4096 bits), though other embodiments may have any different numbers ofregisters of different sizes. In some embodiments, the parser 145 storeseach extracted packet header in a particular subset of one ore moreregisters of the PHV. For example, the parser might store a first headerfield in one 16-bit register and a second header field in a combinationof an 8-bit register and a 32-bit register (e.g., if the header field is36 bits long).

The PHV provides the input data to the match tables of the MAU. In someembodiments the MAU 150 includes a set of match-action stages (e.g., 32match-action stages in some embodiments), each of which matches aparticular set of header fields against a match table and takes anaction based on the result of the match (e.g., assigning the packet toan output port and queue, dropping the packet, modifying one or more ofthe header fields, etc.). The MAU 150 and its different match-actionstages are described in more detail below by reference to FIG. 3. Basedon the actions taken on different header data during the differentstages of the MAU 150, the PHV that the MAU outputs might include thesame header data as the PHV that the MAU received from the parser, orthe output PHV might contain different data than the input PPHV.

The output PHV is then handed to the deparser 155. In some embodiments,the deparser 155 reassembles the packet by putting back together theoutput PHV (that might or might not have been modified) that thedeparser receives from the MAU 150 and the payload of the packet thatthe deparser receives directly from the parser 145 in some embodiments.The deparser then sends the packet out of the ingress/egress pipeline(to the queuing system 120 or out of the switch, depending on whether itis the deparser for the ingress pipeline or the egress pipeline).

FIG. 2 illustrates a block diagram similar to the block diagram 140 ofFIG. 1, except that this figure shows that the parser also produces asecondary packet header vector (SPHV), or tag-along PHV, that bypassesthe MAU's pipeline and is directly delivered to the deparser. Morespecifically, after receiving a packet, the parser 145 of someembodiments produces two different packet header vectors, a PPHV and aSPHV, as its output.

As described above, in some embodiments, for each packet that isprocessed by the switch, the parser separates the packet header data(e.g., Ethernet, IPv4, TCP, etc.) from the payload 220 of the packet anddetermines which fields of each packet header (e.g., source port addressof the TCP header, destination port address of the TCP header, etc.) maybe processed by the MAU (i.e., might be matched against, or might bemodified by an action). Packets may contain packet headers and apayload, though the divide between the two depends on how deep into thepacket an element is inspecting. For instance, for a network elementthat only looks at and operates on the layer 2 (e.g., Ethernet) headers,the layer 3 (e.g., IPv4, IPv6, etc.), layer 4 (e.g., TCP, UDP, etc.)portions are part of the packet payload. However, for a network elementthat uses the layer 4 headers, the layer 2, layer 3, and layer 4portions are all part of the headers, and the remainder of the packet istreated as payload. Each header (e.g., the layer 2 header, layer 3header, layer 4 header, tunnel encapsulations, etc.) may include one ormore header fields, which contain data values. For example, the sourceand destination IP addresses of an IP header (e.g., IPv4 header) are twodifferent header fields of the IP header, while the source port anddestination port addresses of a TCP header are two different headerfields of the TCP header.

The term “packet” is used throughout this application to refer to acollection of bits in a particular format sent across a network. Itshould be understood that the term “packet” may be used herein to referto various formatted collections of bits that may be sent across anetwork. A few examples of such formatted collections of bits areEthernet frames, TCP segments, UDP datagrams, IP packets, etc.

While separating the different packet headers from the payload andseparating the participating header fields from the nonparticipatingheader fields, the parser of some embodiments (1) populates the primarypacket header vector (PPHV) 230 with only the participating headerfields of different headers (i.e., the fields that may be processed bythe MAU), and (2) populates the secondary packet header vector (SPHV)240 with the nonparticipating fields of the different packet headers(i.e., the fields that will not be processed by the MAU).

Each of the PPHV and SPHV includes a set of registers that stores thepacket header fields in some embodiments. For example, and as describedabove, the PPHV 230 of some embodiments includes a combination ofdifferent size registers (e.g., with a total capacity of 4 k bits) thathold the packet header field values that may be processed the MAU.Similarly, the SPHV 240 of some embodiments includes a set of the sameor different size registers (e.g., shift registers, FIFO registers,etc.) for holding non-used header field values (e.g., with a totalcapacity of 2 k bits).

In some embodiments, the parser delivers the populated PPHV 230 to theMAU 150, which includes a set of match-action stages for matching thedifferent header fields of the packet against the different match tablesand applying the required actions to the packet by modifying the packetheader data (e.g., assigning the packet to an output port and queue,sending the packet to a network controller, dropping the packet,modifying the header field values of the PPHV, etc.). The parser of somesuch embodiments also delivers the populated SPHV 240 directly to thedeparser 155 along with the payload of the packet and without having theMAU 150 process the SPHV 240. By carrying the SPHV directly to thedeparser without having the registers sent to the MAU, the wiring of theswitch with respect to these packet header registers is greatlysimplified.

In some embodiments, after the packet headers are processed by the MAU150, the deparser 155 reassembles the packet with (1) the processedheader data (that might or might not have been modified) which thedeparser receives from the MAU 150, (2) the unprocessed header datastored in the SPHV 240 that the deparser receives from the parser 145,and (3) the payload 220 of the packet that the deparser also receivesfrom the parser 145. As described before, after reassembling the packet,if the packet is reassembled by an ingress deparser, the deparser sendsthe packet to a queuing system to be subsequently forwarded to theegress pipeline of the switch. On the other hand, if the packet isreassembled by an egress deparser, the deparser sends the packet (with aheader that might or might not have been modified) out of the switch. Insome embodiments, the deparser recognizes the location in thereconstructed packet at which to place each value from the differentregisters (as an example, the 13 bits of the IPv4 fragment offset fieldthat might be located in register X of the SPHV are inserted directlyafter the 3 bits of the flags field from register Y of the SPHV anddirectly before the 8 bits of the time to live field from register N ofthe PPHV).

FIG. 3 illustrates an ingress/egress pipeline architecture 300 thatseparates the participating header fields (i.e., the header fields thatmay participate in the different match-action stages of the MAU) of thedifferent packet headers from non-participating packet header fields ofa packet. More specifically, the figure shows that the pipeline 300includes a parser 310, an MAU with multiple match-action stages 1through m (where m is an integer such as 32 in some embodiment), and adeparser 360. As illustrated, each match-action stage includes a Xbar315, a set of exact match tables 320, a set of ternary match tables 325,and a Very Long Instruction Word (VLIW) action engine 330.

As described above, the parser 310 receives a packet (e.g., through aset of input modules of the switch) and extracts the packet headers(e.g., Ethernet header, IPv4 header, IPv6 header, TCP header, UPDheader, tunnel encapsulation headers, etc.) from the body of the packet.The parser 310 then separates the header field values that may beprocessed by the MAU from the rest of the header field values in eachpacket header. As stated above, the header fields of a packet header arethe different segments of the packet header, each of which stores aparticular value representing a particular piece of data. For example,an IPv4 packet header includes a source IP address header field, adestination IP address header field, an IPv4 identification field headerfield, a time-to-live header field, etc.

The parser of some embodiments determines which header fields areparticipating header fields (i.e., the fields that may be processed bythe MAU) and which header fields are non-participating header fieldsbased on configuration data that the parser receives from a configuratormodule in the control plane. In some such embodiments, the configuratormodule receives the configuration data from a compiler (also part of thecontrol plane) which generates the configuration data based on a set ofinstructions that the compiler receives (e.g., from a user designing thefunctionality of the hardware switch). The compiler and configuratormodules of some embodiments are described in more detail below byreference to FIG. 5.

While the parser 310 separates the header fields that may be processedby the MAU from the rest of the header fields of the different packetheaders, the parser stores the participating header fields in the PPHV(in different registers of the PPHV) and delivers the PPHV to the MAUfor further processing of the header data. As described above, the MAUof some embodiments includes a set of different stages, each of which isconfigured to process a particular set of header fields of the PPHV. Insome embodiments, each of these stages is reconfigurable by a controllerthat is responsible for configuring (and reconfiguring) the stages ofthe match-action units of the hardware switch to match against variousdifferent packet header fields and

In some embodiments, the output PPHV from the parser 310 is delivered toboth the Xbar 315 and the VLIW action engine 330. The Xbar 315 of eachstage, in some embodiments, includes a set of one or more crossbars(e.g., two crossbars) that identifies which field or fields of the PPHVare used by the match tables of the corresponding stage of the MAU, anddelivers the identified fields to the exact match tables and ternarymatch tables of the stage. For instance if the match tables of aparticular stage are configured to match against a source IP addressfield that is carried by one or more PPHV registers, the Xbar 315 ofthat particular stage takes the IP source field from the PPHVregister(s) and delivers the field to the match tables. In someembodiments, the Xbar 315 operates at a bit level. That is, a particularheader field that contains 20 bits might be carried by a 16-bit registerand a portion of an 8-bit register of the PPHV. The Xbar of some suchembodiments, therefore, passes only 20 bits of the data that is carriedby the combination of the 16-bit register and the 8-bit register to itscorresponding match tables.

As illustrated in FIG. 3, each match-action stage of the MAU includes aset of ternary match tables 325 and a set of exact match table 320. Someembodiments implement (1) the ternary match tables with ternary contentaddressable memory (TCAM) units, and (2) the exact match tables withstatic random-access memory (SRAM) units, that operate as hash tables.Each one of the ternary match tables and exact match tables of someembodiments includes a number of entries (e.g., flow entries) each ofwhich matches against the values of one or more packet header fields andinstructs the action engine 330 of the same stage to take a particularaction (e.g., an action stored in a SRAM unit of an action table).

In some embodiments the ternary match table stores packet header datathat can include ternary bits (i.e., bits with values of 0, 1 orwildcard). Wildcarding the bits allow a single table entry to match awide variety of packet header fields. The exact match table of someembodiments does not allow any wildcarding, hence the packets mustexactly match the table entries. When the header field is matchedagainst an entry of a match table (a ternary table or an exact matchtable), several pointers which together contain the required informationto perform the desired actions are retrieved from that entry of thematch table. The information, in some embodiments, includes, among otherdata, an instruction memory address for the action engine 320 and anaction memory address and size. The desired actions include simpleactions such as setting a field in the PPHV to a particular value ordropping a packet, as well as complex operations, such as addingencapsulations to the packet (e.g., Provider Backbone Bridges (PBB)encapsulation, GRE or GENEVE tunneling, etc.).

In some embodiments, the VLIW action engine 330 includes differentaction operations that may receive their sources from packet headerfields (which is why a copy of the PPHV registers are directly deliveredto the action unit), or from an action memory (not shown). An actionindicated by a match may be simple and require only a small amount ofdata from the action memory or complex and require a large amount ofdata. When the action engine 330 receives the action data (from theaction memory or the PPHV), the action engine takes the required actionwhich may include modifying a header field in the PPHV (e.g., todecrement the TTL field of the IP header, change the address of thepacket, etc., or taking another action such as assigning the packet toan output port and/or queue, sending the packet to the controller,dropping the packet, etc. After the required action is taken (e.g., whena match is found) in each stage of the MAU, the PPHV (as modified by theaction, if such modifications are performed) is delivered to the nextstage of the MAU for further processing. In some embodiments, eachsuccessive PPHV that includes the packet header data of one packetprogresses through the pipeline of match-action stages one clock cyclebehind the previous PPHV.

The last match-action stage of the MAU, after processing the PPHV,delivers the processed PPHV to the deparser 360. As described above,after receiving the PPHV of a particular packet from the MAU, thedeparser 360 of some embodiments reassembles the packet by puttingtogether the processed header fields that are received from the MAU,with the unprocessed header fields that are received directly from theparser 310 in the SPHV 355 and the payload 350 of the packet that isalso received directly from the parser 310. The packet is then eithersent out of the switch (if the deparser is an egress deparser), or sentto the queuing system (if the deparser is an ingress deparser) forfurther processing by the egress pipeline of the switch.

FIG. 4 conceptually illustrates the reason that the parser of someembodiments does not store the entire packet headers in the PPHV to beprocessed by the MAU. This figure shows that a packet 410 is beingreceived by the parser 420 to parse the packet headers into the PPHV430. However, not every header field of each packet header is needed bythe MAU stages of the upcoming ingress or egress pipeline to which theparser sends the PPHV. For instance, some of the packet header fieldswill (i) not be matched against by any of the match entries of the matchtables in the pipeline and (ii) not be modified by any possible actionentry that could be performed in the pipeline. Thus, as the parser 420extracts each packet header from the packet 410, it determines which ofthe header fields of the packet header might be processed by at leastone of the match-action stages of the MAU.

The illustrated example shows that a packet header 415 (e.g., anEthernet header, IPv4 header, etc.) of the packet 410 includes severalparticipating header fields 450 that the MAU is configured (e.g., by aconfigurator module of the control plane) to potentially process. At thesame time, the packet header 415 also includes several othernon-participating header fields 460 that the MAU is not configured toprocess. In some embodiments, when the parser 420 extracts a particularpacket header from the packet 410, the parser must extract the entirecontiguous packet header at once (i.e., the parser cannot leave certainfields of a packet header in the payload while placing the other fieldsof the packet header in the PHV). Because the different participatingheader fields of the packet header are often not placed next to eachother in the packet header (as illustrated in the figure), the parser ofsome embodiments separates these participating header fields fromnonparticipating fields during extraction of the packet header.

For example, the MAU might be configured to process only a particularset of header fields in a UDP packet header, which may not be the firsttwo header fields of the packet header (i.e., the source and destinationports). In such a case, the parser locates the particular header fieldsin the set, pulls these fields out of the packet header, and stores theheader fields in the PPHV. However, the other nonparticipating headerfields that are also extracted from the packet have to be dealt with aswell. Therefore, in some embodiments, the parser 420 looks at eachheader field in the packet header and determines whether the identifiedheader field might be processed by the MAU or will definitely not beprocessed by the MAU. Though not the case in this example, in someembodiments none of the fields of a packet header might be placed in thePPHV, but the parser would extract these fields and place them in theSPHV in order to continue deeper into the packet and place the fields ofa higher-layer packet into the PPHV.

If the parser 420 determines that the header field is one of theparticipating header fields, the parser stores the header field in thePPHV 430 (i.e., in a particular set of registers of the PPHV 430designated for that header field). On the other hand, if the parser 420determines that the identified header field is not supposed to beprocessed by the MAU, the parser stores the header field in the SPHV 440to be subsequently sent directly to the deparser (not shown) of thepipeline without getting processed.

The parser of some embodiments determines which fields of each packetheader may be processed and which fields will not be processed by theMAU, based on the information the parser receives from the packet itself(e.g., by one or more particular packet header of the packet), and basedon the configuration data received from a compiler in the control plane.In some embodiments, the compiler receives the data required forconfiguring the pipeline (e.g., through a programing language code),generates a set of configuration data, and distributes the generateddata to a configurator module (also in the control plane). Theconfigurator module then distributes the configuration data to bothparser and MAU of the pipeline in the switch (e.g., at run-time orduring setup time).

FIG. 5 conceptually illustrates a block diagram 500 of a parser that isconfigured by a compiler to separate the participating packet headerfields from non-participating header fields. Specifically, this figureshows a parser 510, a compiler 520, a configurator 530, and an MAU 540.The parser 510 of some embodiments includes an extractor state machine560. In some embodiments, the compiler 520 and configurator 530 areseparate from the hardware switch (i.e., not part of the chip), whereasthe parser 510 and MAU 540 are part of the hardware switch circuitry.The configurator 530, in some embodiments, represents a runtime networkcontroller stack that configures the hardware switch, while the compiler520 operates at an earlier stage to generate the configuration data andprovide this configuration data to the configurator 530.

In some embodiments, the compiler 520 generates configuration data forthe hardware switch based on a switch configuration received by thecompiler 520 (e.g., through code written by a user, such as P4 code fordesigning switch operations). The configuration data specifies how toprogram the match-action stages of the MAU 540 to implement the switchconfiguration specified by the received configuration code, as well ashow to program the extractor state machine 560 of the parser to extractthe packet header fields correctly and to place the packet header fieldsinto the appropriate PPHV or SPHV registers.

The compiler 520 passes the configuration data to the configurator 530,which provides the configuration data to the MAU 540 so that the MAU canimplement the appropriate switch configuration. In addition, theconfigurator 530 provides the parser configuration data generated by thecompiler 520 to the extractor state machine 560 so that the extractorstate machine can extract header fields from the packets into theregisters of the PPHV and the SPHV.

The extractor state machine 560 receives the packet 585 and (i)separates the packet headers into the PPHV 570 and the SPHV 575 and (ii)separates out the payload 580 of the packet. In some embodiments, theextractor state machine begins at the front of the packet (i.e., theoutermost headers) and works inward, extracting each packet header fieldinto either the PPHV or the SPHV. For certain header fields, theextractor state machine looks at the value and compares the value toconfiguration entries (e.g., TCAM entries), which specify how the nextset of packet header fields should be extracted.

The extractor state machine 560 follows a parse graph that specifiesnumerous states at which a particular packet header field is extractedinto either the PPHV or the SPHV, as well as what state of the parsegraph to proceed to next. That is, in some embodiments each statespecifies which bits of the header to extract for a particular headerfield, which register(s) of the PPHV or SPHV to put those bits into, andto which state to proceed next. The extractor state machine 560 of someembodiments may also read the data of certain header fields in order todetermine which path to take through the set of states of the parsegraph. For example, the EtherType field of an Ethernet header indicatesthe type of protocol encapsulated by the Ethernet header (e.g., IPv4,IPv6, ARP, etc.). The different fields of these protocols will beformatted differently, so for the extractor state machine 560 toproperly identify the next state(s) in the parse graph, it needs to knowthe EtherType value. Similarly, the protocol field of an IPv4 headerspecifies the transport layer protocol (e.g., TCP, UDP, etc.), whichwill determine how those fields are extracted.

In some embodiments, the parse graph is implemented in the parser 530 asa set of entries in TCAMs that the extractor state machine matches. Thepacket header is received as a set of bits stored in, e.g., a buffer,and at any time during the extraction process a pointer points to aparticular location in the buffer. The TCAM entries of the parse graphof some embodiments specify which type of header is next based on thevalue of certain fields of a current header (e.g., the EtherType fieldof an Ethernet header, the protocol field of an IPv4 header, etc.), andhow to extract the header fields of the next header. This entailsspecifying how many bits to extract for each header field in the nextheader, to where in the sets of registers of the PPHV and the SPHV eachheader field should be extracted, and to where in the buffer to move thepointer for the next header field. As mentioned, for certain fields, theheader field value is matched against the TCAM entries to determine thenext state or set of states based on the determination as to what typeof packet headers are contained in the packet.

The parser configuration specifies which packet headers will beextracted into the PPHV and which packet headers are extracted into theSPHV. In some embodiments, any field that is either (i) used as a matchfield of any match entry in the MAU and/or (ii) modified by any actionentry in the MAU is extracted into the PPHV, with only the header fieldsthat are not involved in any way with the MAU extracted into the SPHV.Thus, for some packets, some of the header fields in the PPHV will notactually be used or modified by the MAU (especially if one of theearlier stages instructs the switch to drop the packet). Identifying allof the fields that will be used on a packet-by-packet basis wouldeffectively entail performing the match-action pipeline (because thevalues of the header fields would have to be considered for each stageto determine which actions to take, and the actions performed to findthe new values for the header fields in order to identify which fieldsare considered at subsequent stages). Thus, the extractor state machine560 of some embodiments only reads and matches against the values forcertain header fields that identify the structure of the subsequentpacket headers, so that the subsequent packet headers can be extractedproperly according to the parse graph.

Separating the fields that may be processed by the MAU from the rest ofthe fields in each packet header improves the overall efficiency of theswitch in many ways. For instance, this separation helps avoid wastingthe valuable resources of the MAU by enabling these resources to only(or primarily) process data that is actually needed for making thepacket processing determinations. For example, a TCP packet headertypically has a minimum length of five words (twenty bytes). In manycases, the MAU of the pipeline processes only four bytes of the TCPheader bytes (i.e., the source and destination port addresses) and therest of the fields in the TCP header (sixteen bytes) are not used by anyof the stages of the MAU. In such cases, by separating the unused datafrom useful data, the parser does not waste any of the valuableresources of the MAU to process the other sixteen bytes of the TCPheader.

In addition, separating the PPHV form the SPHV enables the parser toparse deeper into packets while sending the same amount of data to theMAU (via the PPHV). While using a single PPHV of a fixed size onlyallows the parser to extract the packet headers up to a certain point(the size of the PPHV), sending some of the unused fields into the SPHVallows the PPHV to carry only the more useful fields, and include deeperpacket headers. For example, newer tunneling protocols such as GENEVEadd variable length option fields to the packet header, and may be quitelong. Similarly, packets sent using multi-layer tunneling may havesignificant amounts of packet header data that may need to be extractedin order to reach the layer 4 (e.g., TCP) data. By sending the fieldsthat will not be processed by the MAU to the SPHV, the PPHV can includepacket header fields that are located deeper into the packet, withoutsending additional data to the MAU.

FIG. 6 conceptually illustrates a process 600 of some embodiments thatpopulates the PPHV and SPHV with different header field values (e.g.,source and destination port addresses, fragmentation offset field,transport layer ports, encapsulation addresses, etc.) of a packet header(e.g., IPv4, TCP, UDP, etc.). The process 600 of some embodiments isperformed by an extractor state machine of a ingress parser or egressparser of a hardware switch in some embodiments, such as the extractorstate machine 560 illustrated in FIG. 5.

The process 600 initiates by receiving (at 610) a packet header. In someembodiments the process receives the packet header from a packetreceiver module of the parser, such as the packet receiver 550 of FIG.5. A packet header could be an Ethernet header, an IP header, a TCPheader, etc. In addition, in some embodiments, the process has learned(e.g., from examining a previous packet header field), the format of thereceived packet header (i.e., what type of packet header it is, andtherefore the lengths of the different fields of the packet header.

The process then extracts (at 620) the next header field of the receivedpacket header. As described above, in some embodiments the extractorstate machine points to a particular location in a buffer that holds thepacket header, and the parser configuration (implementing the parsegraph) identifies the length of the next packet header, starting fromthat particular location. Thus, to extract the next header field, theprocess extracts the specified next number of bits (and, in someembodiments, moves the pointer to the new location after the lastextracted bit).

The process then determines (at 630) whether the extracted field may beprocessed by any of the match-action stages of the MAU. When the processdetermines that the extracted field is a participating header field thatcould be used at some point during the processing of the PPHV throughthe different stages of the MAU, the process identifies (at 640) acontainer (e.g., one or more registers of the PPHV) in the PPHV andstores the extracted header field in the identified container of thePPHV. On the other hand, if the process determines that the extractedfield is a nonparticipating header field, which will not processed byany match-action stage of the MAU, the process identifies (at 650) acontainer (e.g., one or more registers of the SPHV) in the SPHV andstores the extracted header field in the identified container of theSPHV.

As described above, in some embodiments operations 620-640 or 620-650are all performed as a single operation. Specifically, the determinationas to whether a particular field may be processed by the MAU is madeduring the generation of the parse graph, (according to theconfiguration data) and embedded in the parse graph based on whether theparse graph instructions specify to store the particular header field inthe PPHV or the SPHV. Thus, the extractor state machine of someembodiments extracts the header field (i.e., the next X bits of thepacket header) into a specific register of either the PPHV or the SPHV,without performing any specific analysis at packet processing time as towhether the header field is a participating or non-participating headerfield.

After storing the extracted header field in one of the PPHV or the SPHV,the process of some embodiments determines (at 660) whether anyadditional header fields remain to be extracted. In some embodiments,the parse graph proceeds to the next state according to the instructionsof the previous state, and each subsequent state identifies the next setof bits (i.e., the next header field) to extract. Upon reaching the lastfield to extract, the parse graph state specifies that the extractionprocess is done, at which point the process ends. Thus, when the parsegraph state moves the pointer and specifies the next set of bits toextract, the process 600 returns to 620.

One of ordinary skill in the art will recognize that the specificoperations of the process 600 may not be performed in the exact ordershown and described above. Additionally, the specific operations may notbe performed in one continuous series of operations, and differentspecific operations may be performed in different embodiments. Forinstance, as mentioned above, in some embodiments the process actuallyextracts the field directly into one of the containers of the PPHV orthe SPHV, with the determination at 630 being conceptual. In otherembodiments, the process 600 identifies the packet headers first andthen performs the extraction of the header fields in the identifiedpacket headers. More specifically, in some such embodiments, the processfirst extracts the first packet header (e.g., based on the configurationdata and the parse graph) and after identifying the packet header,extracts the different header fields of the packet header and storesthem either in the PPHV or the SPHV. Furthermore, the process could beimplemented using several sub-processes, or as part of a larger macroprocess.

As mentioned, the compiler of some embodiments generates theconfiguration data for the different switch elements including both theMAU and the parser. The MAU configuration data specifies entries formatch and action tables (implemented in TCAMs, or a combination of TCAMsand RAM) of the packet processing pipelines that enable the switch tomodify, forward, etc. packets that it receives. The parser configurationdata specifies how the parser processes different types of packets, toextract header fields correctly, and to place the extracted headerfields into the appropriate containers of the PPHV and SPHV.

FIG. 7 conceptually illustrates a compiler 700 of some embodiments forgenerating parser and MAU configuration data. As shown, the compilerincludes a code receiver 705, control and table flow graph generator710, MAU configuration generator 715, parse graph generator 720, andparser configuration generator 725. The code receiver 705 receives codedefining the switch operations (e.g., as written by a switch designer,network administrator, etc.), and passes this code to the graphgenerators 710 and 720 (possibly after translating the code into adifferent format if needed). In some embodiments, the code is receivedas P4 code.

The control and table flow graph generator 710 uses the received code togenerate the possible flows through a set of match and action tablesthat the switch will implement. In some embodiments, the flow graph(s)may be linear or branched, depending on the nature of the code receivedby the compiler. As shown in the figure, the flow graph generator 710outputs a flow graph 730, that includes numerous match-action stages.Each match-action stage includes a set of match entries that specify oneor more packet header fields (or other data that is not actually part ofthe packet header, such as ingress or egress ports) over which packetswill be matched, as well as corresponding action entries that specifyactions to take when a packet matches the associated match entry. Theseactions may include modifying certain packet header fields, in additionto other actions (e.g., dropping the packet, modifying non-header fielddata about the packet). The MAU configuration generator 715 uses thecontrol and table flow graphs to generate the MAU configuration entries,in some embodiments.

The parse graph generator 720 of some embodiments uses the received codeto generate a parse graph specifying the possible paths that a parsercan take to parse a received packet. Though shown here as generated fromthe code, in some embodiments the parse graph is information stored withthe compiler, which specifies how to parse any packet. In otherembodiments, some of the information (how any packet might be parsed) isstored with the compiler, but a parse graph for the particular switch isgenerated based on information in the code that indicates what types ofpacket may actually be processed by the switch (e.g., if all packetswill only have Ethernet as the layer 2 protocol).

As shown, the parse graph generator 720 outputs a parse graph 735. Theparse graph, initially, conceptually describes the different types ofpacket headers that could be received by the switch, and the order inwhich those packet headers are arranged. The figure also shows a portionof this parse graph, including the Ethernet header. As shown, the parsegraph 735 specifies (i) how to parse the current header into fields and(ii) how to proceed from the current header to the next header,depending on the value of one or more of the fields of the currentheader. For the Ethernet header, the first eight bytes are the preamble(and start frame delimiter), the next twelve bytes are the destinationMAC address and the source MAC address, and the last two bytes are theEtherType field. In addition, the edges of the parse graph exiting theEthernet header node are dependent on the value of the EtherType field.For instance, if the EtherType field value is 800, then the next headeris IPv4 (with the IPv4 node of the parse graph specifying how to parsethe IPv4 header); if the EtherType field value is 806, then the nextheader is ARP, etc. The parse graph 735 continues in this manner untilreaching a point at which additional data will not be parsed, and thisadditional data is treated as the payload. In some embodiments, theparse graph (prior to being converted into parser configuration data)continues through the entire packet.

The parser configuration generator 725 uses the parse graph 735 as wellas the control and table flow graphs 730 to generate configuration dataused to configure the parser in the hardware switch pipeline. The parserconfiguration data, in some embodiments, includes TCAM entries for eachedge of the parse graph that is relevant to the switch (i.e., for eachpacket header that the switch might need to process). Each of theseentries matches over the packet header field values in the currentpacket header that specify the type of the next packet header (e.g., theEtherType field, the protocol field of an IP packet, etc.). In someembodiments, the TCAM entries point to actions (e.g., in RAM) thatspecify how to parse the subsequent header (e.g., how to parse thevarious different fields of an IPv4 packet, an ARP packet, etc.).

In addition, the parser configuration generator 725 determines whichfields of each packet header might actually be used in the match-actionunit based on the flow graphs 730. In some embodiments, any packetheader field that appears in at least one match entry or is modified byat least one action entry is marked for possible use. While the switchwill probably not use the field for every packet containing such aheader field, it might for at least some such packets (and for certainfields, the switch may use the field for almost every packet thatcontains the field). Some embodiments annotate the parse graph toidentify the participating and non-participating header fields. Thisinformation is then included in the configuration data for the parser,which specifies to send the participating header fields to particularregisters of the PPHV and the non-participating header fields toparticular registers of the SPHV. In some embodiments, the configurationdata also specifies when to stop parsing the packet headers and treatthe remainder of the packet as payload. This decision may be made basedon the amount of data already stored in the PHVs for the currenttraversal through the nodes of the parse graph, or because the end ofrelevant packet headers for the switch have been reached (e.g., the endof the innermost layer 4 headers).

FIG. 8 conceptually illustrates a process 800 performed by the compilerof some embodiments to generate parser configuration data for a hardwareswitch that parses packet header data into a PPHV and a SPHV. As shown,the process 800 begins by receiving (at 805) code for programming thehardware switch. In some embodiments, the code is received as P4 code,describing how the switch should function.

The process then generates (at 810) a parse graph from the code and/orpre-defined packet specifications. In some embodiments the parse graphis information stored with the compiler, which specifies how to parseany packet. In other embodiments, some of the information (how anypacket might be parsed) is stored with the compiler, but a parse graphfor the particular switch is generated based on information in the codethat indicates what types of packets may actually be processed by theswitch (e.g., if all packets will only have Ethernet as the layer 2protocol).

The parse graph of some embodiments conceptually describes the differenttypes of packet headers that could be received by the switch, and theorder in which those packet headers are arranged. Each node in the parsegraph represents a packet header, and the parse graph specifies (i) howto parse the header into packet header fields and (ii) how to proceedfrom the current header to the next header, depending on the value ofone or more of the fields of the current header. For the Ethernetheader, for example, the first eight bytes are the preamble (and startframe delimiter), the next twelve bytes are the destination MAC addressand the source MAC address, and the last two bytes are the EtherTypefield. The edges of the parse graph exiting each node are dependent onthe value of one or more of the field values of the current field.

The process 800 also generates (at 815) control flow and table flowgraphs for defining the match-action stages of the switch. In someembodiments, the flow graph(s) may be linear or branched, depending onthe nature of the code received by the compiler. Each match-action stagein the table flow graph includes a set of match entries that specify oneor more packet header fields (or other data that is not actually part ofthe packet header, such as ingress or egress ports) over which packetswill be matched, as well as corresponding action entries that specifyactions to take when a packet matches the associated match entry. Theseactions may include modifying certain packet header fields, in additionto other actions (e.g., dropping the packet, modifying non-header fielddata about the packet).

Based on the control and table flow graphs, the process 800 determines(at 820) whether each packet header field specified in the parse graphparticipates in the match-action stages. The process annotates (at 825)the parse graph with whether each header field will be placed into thePPHV or the SPHV. In some embodiments, any packet header field thatappears in at least one match entry or is modified by at least oneaction entry is marked for possible use. While the switch will probablynot use the field for every packet containing such a header field, itmight for at least some such packets (and for certain fields, the switchmay use the field for almost every packet that contains the field).Participating packet header fields are marked to be sent to the PPHV,while non-participating packet header fields are marked to be sent tothe SPHV.

Finally, the process 800 generates (at 830) configuration entries forthe parser based on the annotated parse graph. The parser configurationdata, in some embodiments, includes TCAM entries for each edge of theparse graph that is relevant to the switch (i.e., for each packet headerthat the switch might need to process). Each of these entries matchesover the packet header field values in the current packet header thatspecify the type of the next packet header (e.g., the EtherType field,the protocol field of an IP packet, etc.). In some embodiments, the TCAMentries point to actions (e.g., in RAM) that specify how to parse thesubsequent header (e.g., how to parse the various different fields of anIPv4 packet, an ARP packet, etc.).

The configuration data for the parser also specifies to send theparticipating header fields to particular registers of the PPHV and thenon-participating header fields to particular registers of the SPHV. Insome embodiments, the configuration data also specifies when to stopparsing the packet headers and treat the remainder of the packet aspayload. This decision may be made based on the amount of data alreadystored in the PHVs for the current traversal through the nodes of theparse graph, or because the end of relevant packet headers for theswitch have been reached (e.g., the end of the innermost layer 4headers).

Some of the above-described features and applications are implemented assoftware processes that are specified as a set of instructions recordedon a computer readable storage medium (also referred to as computerreadable medium). When these instructions are executed by one or moreprocessing unit(s) (e.g., one or more processors, cores of processors,or other processing units), they cause the processing unit(s) to performthe actions indicated in the instructions. Examples of computer readablemedia include, but are not limited to, CD-ROMs, flash drives, RAM chips,hard drives, EPROMs, etc. The computer readable media does not includecarrier waves and electronic signals passing wirelessly or over wiredconnections.

In this specification, the term “software” is meant to include firmwareresiding in read-only memory or applications stored in magnetic storage,which can be read into memory for processing by a processor. Also, insome embodiments, multiple software inventions can be implemented assub-parts of a larger program while remaining distinct softwareinventions. In some embodiments, multiple software inventions can alsobe implemented as separate programs. Finally, any combination ofseparate programs that together implement a software invention describedhere is within the scope of the invention. In some embodiments, thesoftware programs, when installed to operate on one or more electronicsystems, define one or more specific machine implementations thatexecute and perform the operations of the software programs.

FIG. 9 conceptually illustrates an electronic system 900 with which someembodiments of the invention are implemented. The electronic system 900can be used to execute any of the control, virtualization, or operatingsystem applications described above. The electronic system 900 may be acomputer (e.g., a desktop computer, personal computer, tablet computer,server computer, mainframe, a blade computer etc.), phone, PDA, or anyother sort of electronic device. Such an electronic system includesvarious types of computer readable media and interfaces for variousother types of computer readable media. Electronic system 900 includes abus 905, processing unit(s) 910, a system memory 925, a read-only memory930, a permanent storage device 935, input devices 940, and outputdevices 945.

The bus 905 collectively represents all system, peripheral, and chipsetbuses that communicatively connect the numerous internal devices of theelectronic system 900. For instance, the bus 905 communicativelyconnects the processing unit(s) 910 with the read-only memory 930, thesystem memory 925, and the permanent storage device 935.

From these various memory units, the processing unit(s) 910 retrievesinstructions to execute and data to process in order to execute theprocesses of the invention. The processing unit(s) may be a singleprocessor or a multi-core processor in different embodiments.

The read-only-memory (ROM) 930 stores static data and instructions thatare needed by the processing unit(s) 910 and other modules of theelectronic system. The permanent storage device 935, on the other hand,is a read-and-write memory device. This device is a non-volatile memoryunit that stores instructions and data even when the electronic system900 is off. Some embodiments of the invention use a mass-storage device(such as a magnetic or optical disk and its corresponding disk drive) asthe permanent storage device 935.

Other embodiments use a removable storage device (such as a floppy disk,flash drive, etc.) as the permanent storage device. Like the permanentstorage device 935, the system memory 925 is a read-and-write memorydevice. However, unlike storage device 935, the system memory is avolatile read-and-write memory, such a random access memory. The systemmemory stores some of the instructions and data that the processor needsat runtime. In some embodiments, the invention's processes are stored inthe system memory 925, the permanent storage device 935, and/or theread-only memory 930. From these various memory units, the processingunit(s) 910 retrieves instructions to execute and data to process inorder to execute the processes of some embodiments.

The bus 905 also connects to the input and output devices 940 and 945.The input devices enable the user to communicate information and selectcommands to the electronic system. The input devices 940 includealphanumeric keyboards and pointing devices (also called “cursor controldevices”). The output devices 945 display images generated by theelectronic system. The output devices include printers and displaydevices, such as cathode ray tubes (CRT) or liquid crystal displays(LCD). Some embodiments include devices such as a touchscreen thatfunction as both input and output devices.

Finally, as shown in FIG. 9, bus 905 also couples electronic system 900to a network 965 through a network adapter (not shown). In this manner,the computer can be a part of a network of computers (such as a localarea network (“LAN”), a wide area network (“WAN”), or an Intranet, or anetwork of networks, such as the Internet. Any or all components ofelectronic system 900 may be used in conjunction with the invention.

Some embodiments include electronic components, such as microprocessors,storage and memory that store computer program instructions in amachine-readable or computer-readable medium (alternatively referred toas computer-readable storage media, machine-readable media, ormachine-readable storage media). Some examples of such computer-readablemedia include RAM, ROM, read-only compact discs (CD-ROM), recordablecompact discs (CD-R), rewritable compact discs (CD-RW), read-onlydigital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a varietyof recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.),flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.),magnetic and/or solid state hard drives, read-only and recordableBlu-Ray® discs, ultra density optical discs, any other optical ormagnetic media, and floppy disks. The computer-readable media may storea computer program that is executable by at least one processing unitand includes sets of instructions for performing various operations.Examples of computer programs or computer code include machine code,such as is produced by a compiler, and files including higher-level codethat are executed by a computer, an electronic component, or amicroprocessor using an interpreter.

While the above discussion primarily refers to microprocessor ormulti-core processors that execute software, some embodiments areperformed by one or more integrated circuits, such as applicationspecific integrated circuits (ASICs) or field programmable gate arrays(FPGAs). In some embodiments, such integrated circuits executeinstructions that are stored on the circuit itself

As used in this specification, the terms “computer”, “server”,“processor”, and “memory” all refer to electronic or other technologicaldevices. These terms exclude people or groups of people. For thepurposes of the specification, the terms display or displaying meansdisplaying on an electronic device. As used in this specification, theterms “computer readable medium,” “computer readable media,” and“machine readable medium” are entirely restricted to tangible, physicalobjects that store information in a form that is readable by a computer.These terms exclude any wireless signals, wired download signals, andany other ephemeral signals.

While the invention has been described with reference to numerousspecific details, one of ordinary skill in the art will recognize thatthe invention can be embodied in other specific forms without departingfrom the spirit of the invention. In addition, a number of the figures(including FIGS. 6 and 8) conceptually illustrate processes. Thespecific operations of these processes may not be performed in the exactorder shown and described. The specific operations may not be performedin one continuous series of operations, and different specificoperations may be performed in different embodiments. Furthermore, theprocess could be implemented using several sub-processes, or as part ofa larger macro process. Thus, one of ordinary skill in the art wouldunderstand that the invention is not to be limited by the foregoingillustrative details, but rather is to be defined by the appendedclaims.

1-20 (canceled)
 21. Network switch circuitry for use with at least onenetwork, the network switch circuitry, when in operation, being toreceive at least one ingress packet via the at least one network andalso being to generate at least one egress packet for being output fromthe network switch circuitry, the network switch circuitry comprising:packet processing circuitry for processing the at least one ingresspacket to generate the at least one egress packet, the packet processingcircuitry being for being programmed for use in (1) identifying headerfield values of the at least one ingress packet that correspond toparticular flow information of the at least one ingress packet, and (2)determining at least one particular action that the network switchcircuitry is to take with respect to the processing of the at least oneingress packet, the packet processing circuitry being programmable, atleast in part, based upon compilation of user-provided programinstruction code, the user-provided program language code describing, atleast in part, (1) manner that the packet processing circuitry is toparse the at least one ingress packet, and (2) match-action tableentries that correlate possible packet flows with corresponding actionsto be taken by the network switch circuitry, the compilation being foruse in generating, at least in part, configuration data for use inprogramming, at least in part, the packet processing circuitry; wherein:the determining of the at least one particular action is to be based, atleast in part, upon the particular flow information and the match-actiontable entries; and the packet processing circuitry is also programmablefor use in packet processing operations related to: packet switching;packet tunneling; packet modification; and packet dropping.
 22. Thenetwork switch circuitry of claim 21, wherein: the packet processingcircuitry is programmable for use in wildcard matching operationsrelated to the match-action table entries.
 23. The network switchcircuitry of claim 22, wherein: the network switch circuitry is for usein association with a network adapter of a server computer; and thenetwork switch circuitry is to receive the at least one ingress packetvia the network adapter.
 24. The network switch circuitry of claim 23,wherein: the packet processing operations are related to: GREprocessing; and/or GENEVE processing.
 25. The network switch circuitryof claim 24, wherein: the header field values comprise at least onesource address value, at least one destination address value, at leastone source port value, at least one destination port value, and at leastone protocol type value.
 26. The network switch circuitry of claim 25,wherein: the configuration data defines, at least in part, match-actiondata of the match-action table entries.
 27. At least one non-transitorymachine-readable medium storing instructions for being executed bynetwork switch circuitry, the network switch circuitry being for usewith at least one network, being to receive at least one ingress packetvia the at least one network, and also being to generate at least oneegress packet for being output from the network switch circuitry, theinstructions, when executed by the network switch circuitry resulting inthe network switch circuitry being configured to perform operationscomprising: processing, by packet processing circuitry of the networkswitch circuitry, the at least one ingress packet to generate the atleast one egress packet, the processing comprising (1) identifyingheader field values of the at least one ingress packet that correspondto particular flow information of the at least one ingress packet, and(2) determining at least one particular action that the network switchcircuitry is to take with respect to the processing of the at least oneingress packet, the packet processing circuitry being programmable, atleast in part, based upon compilation of user-provided programinstruction code, the user-provided program language code describing, atleast in part, (1) manner that the packet processing circuitry is toparse the at least one ingress packet, and (2) match-action tableentries that correlate possible packet flows with corresponding actionsto be taken by the network switch circuitry, the compilation being foruse in generating, at least in part, configuration data for use inprogramming, at least in part, the packet processing circuitry; wherein:the determining of the at least one particular action is to be based, atleast in part, upon the particular flow information and the match-actiontable entries; and the packet processing circuitry is also programmablefor use in packet processing operations related to: packet switching;packet tunneling; packet modification; and packet dropping.
 28. The atleast one non-transitory machine-readable medium of claim 27, wherein:the packet processing circuitry is programmable for use in wildcardmatching operations related to the match-action table entries.
 29. Theat least one non-transitory machine-readable medium of claim 28,wherein: the network switch circuitry is for use in association with anetwork adapter of a server computer; and the network switch circuitryis to receive the at least one ingress packet via the network adapter.30. The at least one non-transitory machine-readable medium of claim 29,wherein: the packet processing operations are related to: GREprocessing; and/or GENEVE processing.
 31. The at least onenon-transitory machine-readable medium of claim 30, wherein: the headerfield values comprise at least one source address value, at least onedestination address value, at least one source port value, at least onedestination port value, and at least one protocol type value.
 32. The atleast one non-transitory machine-readable medium of claim 31, wherein:the configuration data defines, at least in part, match-action data ofthe match-action table entries.
 33. At least one non-transitorymachine-readable storage medium storing instructions for being executedby at least one computing device, the instructions, when executed by theat least one computing device resulting in the at least one computingdevice being configured for performance of operations comprising:generating, at least in part, a compilation of user-provided programlanguage code, the compilation being usable in programming of packetprocessing circuitry of network switch circuitry, the user-providedprogram language code describing, at least in part, (1) manner that thepacket processing circuitry is to parse at least one ingress packet thatis to be received by the network switch circuitry via at least onenetwork, and (2) match-action table entries that correlate possiblepacket flows with corresponding actions to be taken by the networkswitch circuitry, the compilation being for use in generating, at leastin part, configuration data for use in the programming, at least inpart, the packet processing circuitry, the packet processing circuitrybeing for use in processing the at least one ingress packet to generateat least one egress packet that is to be output from the network switchcircuitry, the processing comprising (1) identifying header field valuesof the at least one ingress packet that correspond to particular flowinformation of the at least one ingress packet, and (2) determining atleast one particular action that the network switch circuitry is to takewith respect to the processing of the at least one ingress packet;wherein: the determining of the at least one particular action is to bebased, at least in part, upon the particular flow information and thematch-action table entries; and the packet processing circuitry is alsoprogrammable for use in packet processing operations related to: packetswitching; packet tunneling; packet modification; and packet dropping.34. The at least one non-transitory machine-readable medium of claim 33,wherein: the packet processing circuitry is programmable for use inwildcard matching operations related to the match-action table entries.35. The at least one non-transitory machine-readable medium of claim 34,wherein: the network switch circuitry is for use in association with anetwork adapter of a server computer; and the network switch circuitryis to receive the at least one ingress packet via the network adapter.36. The at least one non-transitory machine-readable medium of claim 35,wherein: the packet processing operations are related to: GREprocessing; and/or GENEVE processing.
 37. The at least onenon-transitory machine-readable medium of claim 36, wherein: the headerfield values comprise at least one source address value, at least onedestination address value, at least one source port value, at least onedestination port value, and at least one protocol type value.
 38. The atleast one non-transitory machine-readable medium of claim 37, wherein:the configuration data defines, at least in part, match-action data ofthe match-action table entries.